home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000255_misckit-reques…aska.et.byu.edu_Tue Sep 6 16:15:54 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  5KB
  1. Return-Path: <misckit-request@alaska.et.byu.edu>
  2. Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
  3.     id AA01038; Tue, 6 Sep 94 16:15:41 -0600
  4. Received: from YVAX2.BYU.EDU by alaska.et.byu.edu; Tue, 6 Sep 1994 16:14:54 -0600
  5. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-9 #7277)
  6.  id <01HGSQOV2NHC9N52VJ@yvax.byu.edu>; Tue, 06 Sep 1994 16:14:21 -0600 (MDT)
  7. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-9 #7277)
  8.  id <01HGSQOJX67K91WC3Y@yvax.byu.edu>; Tue, 06 Sep 1994 16:14:02 -0600 (MDT)
  9. Received: from darth.byu.edu by alaska.et.byu.edu; Tue,
  10.  6 Sep 1994 16:09:22 -0600
  11. Received: by darth.byu.edu (NX5.67d/NX3.0M) id AA01021; Tue,
  12.  6 Sep 94 16:10:01 -0600
  13. Received: by NeXT.Mailer (1.100)
  14. Received: by NeXT Mailer (1.100)
  15. Date: Tue, 06 Sep 1994 16:10:01 -0600
  16. From: Don Yacktman <don@darth.byu.edu>
  17. Subject: Work in progress...
  18. To: misckit@alaska.et.byu.edu
  19. Reply-To: don@darth.byu.edu
  20. Message-Id: <9409062210.AA01021@darth.byu.edu>
  21. Content-Transfer-Encoding: 7BIT
  22.  
  23.  
  24. Hi there everybody!
  25.  
  26. I've been (and am) busy at work on folding new submissions
  27. and bug fixes into the MiscKit and I'm also improving things
  28. a bit.  I have quite a bit left to do, so it will take a little
  29. while to get the next release out.  Sorry about that, I do
  30. appreciate the patience... if you've sent changes I should be
  31. working on putting them into the kit.  If you don't see them in the
  32. next release _please_ re-send them to me and complain at me!  :-)
  33.  
  34. One of the improvements that I'm working on is changing over
  35. to PB project management for the library projects.  (This is
  36. done via the tool project and a hacked Makefile.[preamble/
  37. postamble] and requires no modifications to PB itself.)  In
  38. the process of moving over, an issue has arisen and I'd like
  39. some input. 
  40.  
  41. Several times in the past we have brought up the possibility
  42. of splitting the main library up into smaller libraries that
  43. can be included as needed so that it is unnecessary to
  44. include the whole big library.  Right now we do have
  45. MiscSwapKit and MiscInspectorKit libraries that are generated
  46. in addition to the main library.  But while I'm switching
  47. over, it would be very easy to divide things up a bit more if
  48. there is demand for it.
  49.  
  50. Reasons for doing this:
  51.     (1)  You don't have to have code for objects you don't use
  52.          included in your app.
  53.     (2)  Objects and categories that don't rely upon the AppKit
  54.          could be placed in a separate lib, thus allowing non-appkit
  55.          apps to use at least that much of the kit.
  56.     (3)  It helps the organization be a bit more coherent.
  57. ...and more stuff someone will probably bring up...
  58.  
  59. Why you might not want to do this:
  60.     (1)  You may have to include more than one library in your
  61.          project and have to know which libraries depend upon each
  62.          other so that you are sure you included all the parts
  63.          that you need.
  64.     (2)  Any project using the MiscKit will need to have minor
  65.          changes made in the PB.project to handle the changes.
  66. ...and more stuff someone will probably bring up...
  67.  
  68.  
  69. Note that when we get NS 4.0, we can do dynlibs, like a
  70. shlib, so #1 of the plusses will become a moot point.  The
  71. MiscKit code wouldn't be in your app anyway in that case.  Of
  72. course, splitting up the kit would make some of the objects
  73. more useful for non-NeXT Obj-C users.  Again, that's a sort
  74. of moot point, though, since the projects will be using PB
  75. for maintenance meaning that non-NS users will need to have
  76. their own Makefiles anyway and that means they could organize
  77. the libs any way they like anyhow.
  78.  
  79. So, I lean toward breaking things up a bit--I still think it
  80. would be worth the effort--but would like to hear everyone
  81. else's thoughts on this.  I think the majority would like to
  82. see this happen, but I'd still like to hear feedback on this.
  83.  
  84. And, for those who like the idea, how should I split things
  85. up?  There have been two basic ideas on this.  The first is
  86. to go for dependencies to delineate organization:  Make a lib
  87. that depends on libsys_a and a second that requires the
  88. appkit.  Then non-appkit users use a part of the kit; appkit
  89. users add in the second part for more functionality.  The
  90. other option is to delineate by function; this would parallel
  91. what we already have with MiscInspectorKit and MiscSwapKit.
  92. I like this method, but perhaps a mixing of the two divisions
  93. would work best.  Anyway, I'd like to hear how people would
  94. like to see things split up.
  95.  
  96. I think it would be best to discuss this openly on the
  97. misckit list so that everyone can respond and refine the
  98. ideas until we arrive at a sort of consensus.  I suspect that
  99. suggestions made will often parallel how you _use_ the kit;
  100. those who only use a part of the kit will probably suggest
  101. placing that part into a library.  (Like those who only use
  102. MiscString.)
  103.  
  104. So, to summarize:
  105. (1) do you want me to split things up more than they already are?
  106. (2) if so, how do you think they ought to be split?
  107.  
  108. Followups to misckit@byu.edu please.
  109.  
  110. ---
  111. Later,
  112.  
  113. -Don Yacktman
  114. Don_Yacktman@byu.edu